home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d12 / pcmagdoc.arc / SAFARI.DOC < prev    next >
Text File  |  1988-01-19  |  2KB  |  41 lines
  1. «RM70»
  2.     Once you have a copy of SAFARI.COM, the best way to load it is
  3. by making the command the first line in your AUTOEXEC.BAT file. 
  4. (Make sure, of course, that the program itself is either in your root
  5. directory or that you specify the full pathname so that DOS can find
  6. it.)  This ensures that SAFARI will be the first program to load
  7. after DOS is initialized.  SAFARI will hook itself into DOS and be
  8. completely invisible to all remaining programs.
  9.     From that point on, anytime a critical interrupt occurs,
  10. SAFARI will take over.  A window will appear on the screen detailing
  11. the type of error that occured, and showing the contents of the CPU
  12. registers that caused the failed operation.  Figure 1 shows a screen
  13. shot of a SAFARI window caused by executing DIR A: with no disk in
  14. the drive.
  15.     After saving the screen contents under the window, and 
  16. displaying the registers and error information, SAFARI simply passes
  17. control to DOS, which generates the response prompt.  Select from
  18. Abort, Retry, Ignore.  If a valid response is entered, SAFARI will
  19. restore the screen to its previous condition and your application
  20. will continue.  (Note that DOS 3.3 modifies the prompt message.  The
  21. Fail option is either substituted for Ignore, or added to the list. 
  22. Fail differs from Ignore in that the calling program is told that an
  23. error has occured.  Since there are more installations of pre-3.3
  24. DOS, however, I'll stick to the common conventions here. If you're
  25. using 3.3, though, keep the substitution in mind.)
  26.  
  27.  
  28. RUNNING DEBUG WITH SAFARI     I mentioned earlier that DEBUG changes
  29. the Int 24h address to point to itself.  If an Int 24h occurs while
  30. running a program under DEBUG, control is passed to DEBUG and then to
  31. the DOS CEH by a simulated interrupt.  When SAFARI gets control, an
  32. extra three words have been pushed onto the stack by DEBUG.  SAFARI's
  33. register dump will therefore be incorrect, as it relies on stack
  34. position for its arguments.  The same situation would apply if an 
  35. application program were to force Int 24h to pass through its own CEH. 
  36. If you're interested in improving SAFARI to reflect these 
  37. contingencies, you can modify the program to check the Int 24h address
  38. in low memory whenever it is invoked.  If the address is different
  39. than when it was installed, a new CEH has been installed and no stack
  40. dump should be performed.
  41.